home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1434.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.3 KB  |  66 lines
  1. >Date: Fri, 18 Jun 93 15:41:47 BST
  2. >From: "Peter Lister, Cranfield Computer Centre"  
  3. <ccprl@xdm001.ccc.cranfield.ac.uk>
  4. >
  5. >>    I don't think this is correct.  Any url can make use of the #  
  6. directive.
  7. >> It just tells a browser to go to a specific part of a document  
  8. instead of
  9. >> to the beginning.  I don't know of any browsers that actually  
  10. 'generate'
  11. >> these internally.
  12. >
  13. >Misunderstanding. I mean to say that I don't know how or whether
  14. >servers will react to # in a URL; as far as I am aware, browsers  
  15. simply
  16. >react to them when they see them in an HTML file. 
  17.  
  18.  
  19. The # is a delimiter which separates the opaque part of the
  20. URL which is passed to the server from the opaque part of
  21. the URL which is passed to the displaying application.
  22. There is no way you can pass a URL containing # to a server,
  23. as that is precicely what it does not mean.
  24.  
  25. If you want to make a special world around tar files, then
  26. do, but use valid characters. If you want to avoid using
  27. things which might crop up in the file names, then the %
  28. character is there which with non hex characters gives
  29. all sorts of combinations -- like %/ mentioned before to
  30. mean "interpret that which is on the left with respect to
  31. that which is on the left".  You could use this for
  32. tar files too, in your server:
  33.  
  34.     /docs/foo.tar%/bar.c        extraction
  35.     /docs/foo.tar%L            listing
  36.     /docs/foo.tar%LR        deep listing
  37.     /docs/foo.tar            the file itself
  38.  
  39. for example.  Remember that this string will be passed
  40. straight to the server and the client is not allowed
  41. to interpret it at all. The bit to the right of the #
  42. is the reverse: it is never passed to the server,
  43. only the client (the presentation app) can interpret it.
  44.  
  45.  
  46. >Further, is a null search term significant or not? Is "foo?"  
  47. equivalent
  48. >to "foo". I would personally hope NOT, as a null default search term
  49. >could be useful (e.g. to return a catalogue).
  50.  
  51. They are different.  Some servers return the same thing for the
  52. two different URLs.  I am not sure which browsers actually support
  53. an empty search string. I agreee it is logical to do so.  You should
  54. NOT assume any convenmtion for what it means. For example,
  55. if the server ANDs its terms, you might expect he catalogue, while
  56. if it ORs them you would expect nothing back.  If you want to
  57. make the catlogue available, it is MUCH better to make a link
  58. to it from the index cover page.
  59.  
  60. Tim BL
  61.  
  62. >Peter
  63. >
  64. >
  65.  
  66.